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ABSTRACT 


The User Adaptive Language (UAL) is designed to provide a convenient and 
flexible means for man-machine communication in cooperative problem-solving/ 
decision-making efforts. The language is extensible and functionally oriented 
with user control of evaluation and data manipulation. The interactive nature 


of UAL provides a "conversational" environment conducive to dynamic decision 


making. 


The syntax of UAL is simple and straightforward. The function definition 
features provide a means of creating new terms and primitives allowing a 
higher level of sophistication in the communication of ideas. The new 
functions may be compact and stylized or English-like in their use. Con- 
sequently, the problem solver is free to concentrate on what to say rather 
than how to say it. UAL can be a powerful tool in building systems in which 


man and machine can work together to complement each other's capabilities. 
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USER ADAPTIVE LANGUAGE (UAL): 


A STEP TOWARD MAN-MACHINE SYNERGISM* 


1. INTRODUCTION 


This paper describes a communication language between man and machine designed 
to aid our research in man-machine synergism. The overall objective of our 
research is to develop a system and techniques with which man-machine talents 
can be utilized effectively and through which man and machine can "co-evolve" 
in a variety of decision-making and problem-solving situations. 


Research efforts have been concentrated on answering three interrelated ques- 
tions: (1) "What machine capabilities and features, including adaptivity, 
can be built in and what must be left to man-machine interaction?" (2) "What 
type of problems or problem environments from which substantial payoffs can 
be expected are especially in need of this approach?" and (3) "What type of 
language is needed for man-machine communication to enable the man to start 
exploiting the machine capabilities from the early stage of problem conceptu- 
alization and definition through the exploratory and the intuition-guided 
stage of problem solving?" 


Rudimentary models constructed in an attempt to give partial answers to the 
three questions are Gaku,**a system of computer programs which has been 
evolving for several years; Shimoku [Hormann, 1966], a highly complex game- 
like environment with complex payoff-cost functions in which man and machine 
interact in generating and evaluating alternative courses of action to gain 
a high score; and the User Adaptive Language (UAL). 


Only Shimoku and a small part of Gaku were implemented on the Q-32 computer, 
the rest of the Gaku design was hand-simulated at the pencil-and-paper level. 
However, a great deal of insight and experience with live subjects was gained, 
which led to several modifications of all three models. 


This document is a revision of an earlier draft document 
(TM-4539/000/00, dated April 10, 1970). 


a 
Gaku is a Japanese word meaning adaptive. This system was first 
designed and implemented on the AN/FSQ-32 computer in the context 
of artificial-intelligence research [Hormann, 1962, 1964, and 1965]. 
It was later redesigned for man-machine cooperative problem solving 
and was partially implemented on the same computer [Hormann, 1966 
and 1969]. The latest design features, which incorporate team 
planning and problem solving and are aimed at real-world problems, 


are currently being implemented on the IBM 360/67 computer under 
SDC's ADEPT time-sharing system. 
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1.1 NEED FOR DYNAMIC EXTENSIBILITY 


The following is a summarization of the findings that combine our own 
observation and the reflective-introspective comments expressed by experimen- 
tal Shimoku subjects. These findings confirmed our earlier belief that the 
dynamic extensibility of Gaku capabilities, which depends on dynamic 
extensibility of the communication language, is one of the essential features 
in achieving man-machine synergism. 


* Even simple bookkeeping functions of the machine can greatly enhance 
the information-handling capacity of the man, especially in keeping 
track of interrelated elements in a complex situation. However, the 
need for such bookkeeping assistance can arise in so many different 
ways and different situations that a fixed set of predetermined 
machine functions cannot handle all such needs adequately. Pro- 
visions must be made to enable the man to formulate these requests 
to the machine as the need arises. Some clever ways of utilizing 
simple machine functions apparently come about dynamically during 
the interaction when the complexity of the situation exceeds the 
information-handling capacity of the man. When such clever ideas 
are not forthcoming or machine aids are not available, the man 
tends to oversimplify the situation, deliberately (or unconsciously) 
ignoring many interrelated elements and often leading to a premature 
decision or conclusion. This is especially true when complexity 
and time constraints are present simultaneously. 


- Before actually executing their decisions, most subjects ask "what 
if'’ questions either overtly or covertly in order to estimate the 
consequences of the tentative decision steps that have been formu- 
lated. However, the breadth and depth of such "what if" questions 
varies greatly with individuals, even with machine assistance. 
Since exhaustive examination of alternatives in more than three- 
step depth is infeasible (in the Shimoku environment) even by the 
machine, very selective 'what if" explorations are generated during 
the interaction. Understanding how such selectivity is formulated 
dynamically will answer one of the major questions about what 
separates a good problem solver from a poor one. 


* The performance records of the subjects (in terms of the numerical 
"score") show a dramatic separation between those who attacked the 
problem incrementally (immediate or short-term payoffs were 
considered) and those who had strategic plans for the problem 
situation as a whole. Those who scored in between the two groups 
made statements such as: "I had a rather vague plan, but I 
couldn't follow through with it because so many unexpected possi- 
bilities opened up as I played that I got distracted by attractive 
new prospects and deviated from the plan. Then things got too 
confusing, so I gave up the plan and played incrementally." 
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Those who scored highest seemed to have utilized intuitive pattern 
recognition (both spacial and abstract patterns) to structure the 
problem space and to make a rough estimate of cause-and-effect 
relation patterns. 


It is our belief that good planning and selectivity in asking 

"what if'’ questions are related and that they are highly problem 
specific. Cleverness in both activities seems to depend on how 
astutely the subject discerns the idiosyncracies of the problem 
situations and takes advantage of them in formulating his plans and 
his "what if" questions. Such characteristics dictate that 

dynamic extensibility of machine functions is needed beyond the 
predetermined set of machine functions; many of the relevant ques- 
tions and much of the selective exploration cannot be formulated 

at the time of the problem definition. Predetermined machine 
functions, however, should include any machine assistance that will 
make it easier for the man to express his tentative ideas and 
requests for exploration and to delegate certain decision functions 
to the machine once they are defined and identified as useful. 


* The subjects unanimously agreed that visual display of their per- 
formance in graphic form and of environmental changes caused by 
their actions was helpful in assessing previous decisions and 
formulating new ones. However, more sophisticated techniques of 
summarizing the current "state of the environment" are needed 
to display information in a variety of formats and at varying 
levels of aggregation. At one point, the subject may be interested 
in the overall relational aspects; at another point, he may be 
interested in detailed information about one small portion of the 
environment. Again, the need for dynamic definability of man's 
ideas and requests became clear. 


1.2 UAL AS A STEP TOWARD MAN-MACHINE SYNERGISM 


UAL has been designed to fulfill the essential need for dynamic extensibility 
demonstrated by the Shimoku experiments. This extensibility and other features 
of UAL are discussed in Section 2. 


An additional advantage can be gained by the use of UAL for the implementation 
of Gaku. Traditionally, a system is implemented in one language, and another 
language is specially developed to allow for user-oriented and/or problem- 
specific expressions. We have, instead, geared the design of UAL and associated 
techniques to serve both purposes without the compromises that would usually 

be required. 


The basic UAL will be used for initial Gaku implementation and an extended 
UAL will be used for user-Gaku interaction and also for designer-—Gaku 
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interaction in system modification. This will be possible through the use of 
the extensible features of UAL and of the techniques of building problem- 
oriented primitives from which higher-level, problem-oriented functions and 
capabilities can be constructed for the users' convenience. Thus the basic 
UAL can be used in the same manner as other programming languages but extended 
UAL can be made into a higher-level, English-like, and/or highly problem- 
specific language, depending on the users' needs and convenience. 


The extensibility of a language refers to its ability to modify itself--that 
is, its ability to create new primitive terms and functions and to define 

new infix operators. This becomes important when the problem situation 
dictates a new notation that the original language does not accept or when new 
primitive terms and functions are required to reduce complexity. These new 
terms and functions may not be known at the outset but, through interaction, 
new ideas may be generated and the need for new terms and procedures realized. 
Thus, extensibility permits dynamic definition. 


With these features, the user can start interacting with Gaku from the initial 
problem-conceptualization and problem-definition stage and continue to the 
intuition-guided, hunch-generation-and-testing stage of problem-solving (and 
perhaps back to the problem-definition stage to repeat the process). The 
conventional separation between the problem-definition and the problem-solving 
stages caused by specialists or programmers, or by extra languages, is not 
necessary. Gaku implemented on UAL can handle user-defined terms and procedures 
directly, without internal translation or mode changes, since expressions 

in UAL are the basic items that Gaku can understand, generate, and manipulate. 
For partially-defined or ill-defined problems, the problem-definition stage 
cannot be separated from the problem-solving stage because of the iterative 
mature of the two. The former can be thought of as a model-building process 
and the latter as model exercising, expecially when the model includes a man 
to provide the behavioral-procedural information that was not known or could 
not be made explicit at the outset. Gaku can bring these together by allowing 
the undefined portions to be supplied by the user in the light of new informa- 
tion and insight as supported by his own background knowledge and past experi- 
ence. Use of the basic UAL in constructing Gaku and also in defining a given 
problem environment is shown schematically in Figure 1. 


Whenever a new problem environment is considered, the man first introduces a 
set of primitive terms and functions to UAL in order to establish a semantic 
link between basic UAL and the problem environment. Once the semantic linkage 
is established, the Gaku system, which is built on top of UAL, becomes a 
problem-oriented or special-purpose system. Then, given that the primitives 
are adequate, the man can communicate any statement or questions about the 
problem environment and can define any operations in it. In Figure 1, this set 
of primitives is represented by the solid box on the right. 


In practice, however, it will be easier and more efficient conceptually if the 
modeling system is equipped with higher-level terms and operations that are 


System Development Corporation 


28 June 1971 5 T™-4539/000/01 


Conceptual Model of 
the "Real-World" 


Selected portion 
representing the 
current interest 


(Man) 


Model System 


Acquired Information and Information and Processes 
| Capabilities (problem-specific) [ Specific to the Problem \ model 


[ Environment. | 


Acquired Information and | 
Capabilities (general) Problem-Oriented Terms and | 


| Processes (higher-level) | 


Basic Gaku 


executive system and 7 Problem—-Oriented Primitives 


adaptive mechanisms (to establish semantic link) 


Basic UAL (User Adaptive Language) (Problem Independent) 


Figure 1. A schematic diagram depicting man-machine cooperative 
endeavor in both defining a problem (or building a model) 


and solving the problem (or experimenting with the model). 
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more amenable to man's levels of thinking. Representing these is a dotted 
box labeled "Problem-Oriented Terms and Processes (higher-level) ," placed 
on top of the box of "Problem-Oriented Primitives." The model is built on 
top of this. Dotted boxes imply that contents are subject to change and 
expansion. 


Intensive research is still required to make the semantic linkage as easy to 
build as possible so that a user need not feel committed to his first choice 
of primitives but can start with a "quick-and-dirty" version to experiment 
with and change it as he discovers its inadequacies. After we have gained 
experience by building primitives for a number of different problem types, 

we may be able to extract a set of commonly used steps for primitive building. 
From this, a set of "primitive-building primitives" may be made available for 
a quicker and easier definition of new problems. 


When model building becomes truly quick and cheap, man may be encouraged to 
try out different formulations or representations of the same problem situa- 
tion, thus gaining different viewpoints, one of which may reveal a lead to 
an answer or to solution methods that could not have been discovered in any 
other way. 
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Zs DESCRIPTION OF UAL (USER ADAPTIVE LANGUAGE) 


The User Adaptive Language (UAL) is a functionally oriented, extensible, 
problem-solving language. In addition to many new concepts and ideas, the 
language incorporates desirable features from existing languages in a unified 
and consistent manner that makes them easy to use and learn. As well as being 
user adaptive, the language is user oriented. It is hoped that UAL can be 
effectively used by those not directly in the computing field. 


UAL is designed to be used interactively through a remote terminal so that an 
immediate response from the computer is received for each and every input. 
Every expression is evaluated (executed) as soon as it is entered, rather than 
being stored for evaluation at a later time. However, it is possible to 
inhibit evaluation if desired. In addition to a number of available pre- 
defined functions that aid the user in problem-solving, the language has five 
different data types: (1) numbers, (2) character strings, (3) quoted expres-— 
sions, (4) argument maps, and (5) lists. '"Character strings" are useful if 
nonnumerical applications are involved. "Quoted expressions" and "argument 
maps" provide a convenient, flexible, and powerful means of defining new 
functions. These functions may be made English-like in use or compact and 
stylized; they may be general-purpose functions or problem-specific primitives. 
A "list" is composed of groups of data elements which can be treated as a 
unit. Sublists and superlists can be formed into structures or networks. 
These data types, coupled with predefined functions plus the rules for their 
manipulation, make up the User Adaptive Language. 


Some important features of the language are summarized below: 


* The basic data structure in UAL is the list. Elements in a list 
may be numbers, character strings, other lists, or even functional 
expressions. Thus, procedures may be stored and manipulated in 
the same manner as simple data items. In adddition, two or more 
lists may share members so that each is "aware'' of a change in 
the other. 


* There are two types of assignment in UAL: pointer changing and 
value changing. Each variable "points to" and is separate from 
its value. Thus, either the value itself may be changed, or the 
variable may be caused to point to a new value. 


¢ Arbitrary functions and infix operators may be defined or redefined, 
depending upon the user's preference. New terms and primitives 
may be created to fit specific needs in a given problem situation 
and to express complex ideas in a clear, readable fashion. The 
user may also make his new functions general and more English-like. 
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* The language is extensible, which means it is capable of redefining 
its own parts. The user may change the action of any built-in 
function or even the way expressions are processed after entry. 


* The language is capable of supporting a semantic linkage for a 
given problem environment by defining a set of problem-oriented 
primitives. This allows more specialized problem-oriented languages 
to be built upon it. 


+ The normal mode of UAL is evaluation. Expressions are evaluated 
(executed) immediately upon entry. This makes the language 
naturally suited for interaction. However, a means is provided to 
suppress evaluation when desired so that expressions may be stored 
and subsequently manipulated without evaluation. 


* A great deal of power and flexibility is provided for functional 
definition. The user has control over argument evaluation, the 
exact place where the function name is to appear, the scope of 
variables, and other features that allow a large variety of func- 
tions to be defined. | 


* The user can specify directly to UAL environmental conditions that 
describe the context within which he will work. UAL will not 
allow these conditions to be violated and will warn the user if 
he attempts to do so. 


The language is described using a somewhat idealized character set for optimum 
understanding of the concepts involved. UAL has been implemented at System 
Development Corporation in Santa Monica, California on the IBM 360/67 ADEPT 
time-sharing system (Linde, et al. [1969]) using LISP 1.5 as the source 
language (Weissman [1967]). 


Zul BASIC ELEMENTS 


The formation of numbers, variables, and character strings follows standard 
rules. Numbers may be integer or real, that is, with or without a decimal 
point. Variables consist of one letter followed by zero or more letters or 
digits. A character string is a sequence of characters enclosed in double 
quote marks. In addition, a number of primitive functions are available for 
forming arithmetic, relational, and logical expressions: 


addition 
subtraction 
multiplication 
division 

integer division 
exponentiation 


> le ~~ & I + 
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Og 


percent 

less than 

less than or equal to 
equal to 

not equal to 

greater than or equal to 
greater than 
identical to 

negation (not) 
disjunction (or) 
conjunction (and) 
implication 
equivalence 
nonequivalence 


Il vv WwW HA A 


MH +} &@ < 2 


These functions are used with parentheses in forming expressions. Each has 
an imposed precedence. (See Appendix B) 


Bue ASSIGNMENT 


Values may be assigned to variables by using the assignment function, back- 
arrow («). For example: 


X<8 


assigns the value 8 to the variable X. The above expression is read, "X is 
defined as 8."" The result of this assignment may be represented graphically 
as follows: 


The picture is intended to show that the variable K is separated from and 
points to its value 8. If the number 8 were assigned to another variable, 


that variable would point to a second representation of the number. For 
example: 


Y<8 
X x 
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It is possible for two or more variables to point to the same value. For 
example: 


Y<X 


would reassign Y to the value that X has: 


Since no variable points to Y's old value, it is lost and its storage space 
may be reused. This "garbage collection" process occurs periodically as 
the need arises. 


X YX 


The backarrow, then, causes a variable to point to a new value. It is also 
possible to change the actual value itself. This, of course, means that 
every variable which points to that value would also be changed. The 
ea that performs this operation is the double backarrow (<«). For 
example: 


Y<<9 
may be read "Y is changed to 9." 


X Y - 


The primitive function “is identical to" (==) may be used to test whether or 
not two variables point to the same value. This function is stronger than 
equals (=), which only tests for equality. 


oa5 LISTS 


A useful data type of UAL is the list. A list is a series of double-pointer 
nodes. The left-hand side points to the value and the right-hand side points 
to the next node. A variable whose value is a list points to the first node 
in the list. The right-hand side of the last node points to an indicator 
that signals the end of the list. To form a list, the elements are written 
sequentially with no punctuation between them and are enclosed in braces. 

For example: 


X<{1 2 3} 


may be pictured as follows: 
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In addition to the brace formation of a list, there is a predefined function 
that causes a list to be formed from its arguments. The function is the comma. 
The above list could have been equivalently specified: 

X<1,253 
It is sometimes necessary to have lists of numbers that are in arithmetic 
progression. However, such lists may be too long to specify explicitly. A 
shorthand notation for such lists is available. For example: 

{2 5 e2 @ 35} 
The above list contains 2 as the first element, 5 as the second element, and 
continues in this manner (that is, incrementing by 3's) until 35 is reached 


or exceeded. 


Sublists and superlists may be formed simply by nesting braces. In this event, 
the left-hand side of the particular node will point to the first node of 
the sublist. For example: 


X+{1 {2 3} 4} 


would produce the following list: 


Xx 


+g 
Co GE 
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Individual elements of a list may be referenced by the locative functions ST, 
ND, RD, and TH. Using the above example: 


3 RD X__s produces 4 
1 ST 2 ND X__ produces 2 


Variables may be assigned to particular parts of a list simply by using the 
assignment arrow and the desired locative functions. 


Y <1 ST X 


will point Y to the number 1, which is the first element of the list X. 

Since the locatives are actually functions, any expression at all may precede 
them as long as an integer is returned as a value. Similarly, in the case of 
lists, any expression at all may be placed inside the braces. The expression 
will be evaluated and the result used as the list member. 


The individual nodes of a list may be accessed with the node-locative functions 
STN, NDN, RDN, and THN. These functions must be used when changing the value 
of elements of a list. 


Most primitive arithmetic and relational functions are defined to iterate 
over the elements of a list. For example: 


3+{2 4} produces {5 7} 


If two lists are used with these functions, their elements are taken one by 
one in parallel from each list. 


{3 5}+{0 2} produces {1 25} 


If one of the lists is short in elements, it is extended with zeros or ones, 
depending upon the particular function involved. 


The list of no elements at all is called the "empty list" and may be written 
in either of the following two ways: 


Lt p 
2.4 | EVALUATION 


Evaluation occurs when an expression is entered into the computer through the 
remote terminal. However, it may be desirable to inhibit the evaluation of 
all or part of the expression. In this way, it can be stored and saved for 
evaluation at a later time. Any expression that is enclosed in single quote 
marks will be inhibited from evaluation. For example: 
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X<~ A+B“ 


produces the following: 


A+B 


The expression A+B is inhibited; X< is not inhibited, so that the assignment 
takes place. Later, if X is called upon to be evaluated, either alone or as 
part of another expression, its value (that is, A+B) will be evaluated also. 
The act of inhibiting is called "quoting" and may be done to any depth. In 
addition to the quote-marks, there is a function that quotes the next complete 
expression after it. It is the colon. The above example could also have 

been written: 


X<+3 A+B 


The predefined function EVAL causes an extra evaluation each time it is used. 
Extra evaluations may be necessary if an expression is quoted more than once. 
The predefined function VALUE may be used to access the value of a variable 
without evaluating it. 


2.5. OPERATIONALS 


An operational is a sequence of two or more expressions that is treated as a 
group--that is, as one expression. The expressions in an operational are 
enclosed in parentheses and may be placed wherever any other single expression 
may be placed. For example, the following is an operational of three expressions: 


(X<+3 Y<{1l 2} Z<"ABC'') 


Since an operational is a single expression, it must have a single value. 

By convention, the value of an operational is the value of the first expression 
in it. The value of the above operational is 3. In the following example, the 
intention is to evaluate (B/3)*H and assign this value to A. However, the 
assignment B<«A is meant to be performed after the division by 3 but before 

the multiplication by H: 


A<(B/3 B<A) *H 


The return value of an operational may be reset by using the function SETOP. 
An interrupt of the normally sequential evaluation of the expressions in an 
operational may be caused with the function RETURN. An operational may also 
be thought of as a single expression followed by a series of side effects. 
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2.6 FUNCTIONS 


A quoted expression is a simple function of no arguments and is evaluated when 
its name is evaluated. To define a function with arguments, the bound variables 
of that function must be listed, enclosed in brackets, [], and placed in front 
of the quoted expression (function definition). The list of bound variables is 
called the argument map. | 


For example: 


F<[X Y]:X+Y+2 
defines a function F of 2 arguments X and Y such that F equals X+Y+2. In order 
to call F, its name should be given, followed by 2 arguments (expressions), 
either alone or in another expression. For example: 

F 2 3 


would produce 7 as a result. No parentheses, commas, or other punctuation are 
used in a function call. However, since a function name plus its arguments 
form a complete expression, parentheses may be placed around the entire group. 


The arguments may be any expression at all including other function calls. 

A function always has as many arguments as bound variables in the argument map. 
If a function is called with fewer arguments than it needs, a sufficient 
number will be supplied. For example: 


(F 4) 


would produce 6 with zero being supplied for Y. 
2.7 ARGUMENT MAP 


The argument map has many features that make function definition powerful and 
flexible. 


An argument may be received in quoted form, even though it is not explicitly 
quoted at call time. This is indicated by placing single quote marks around 
the bound variable in the argument map. For example: 


F<["X* Y]:(P<X Q«Y) 


The above function assigns its two arguments to P and Q, respectively, but asks 
for its first argument in quoted form. 


F At+2 3+2 


would assign the expression At+2 to P and the value 5 to Q. 
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Function calls may be made more readable by using "noise words.’ These are 
variables that are enclosed in parentheses and may be used as optional words 
in the function call. For example: 


MOVE<[ (THE) X (FROM) Y (TO) Z]:definttton 
The function MOVE could be called in either of the following two ways: 


MOVE PIECE SQUARE] SQUARE2 

MOVE THE PIECE FROM SQUARE1 TO SQUARE2 
Functions may possess variables that do not pick up a value from an argument. 
These "local variables" are considered undefined every time the function is 


called. They are listed after the regular bound variables and separated from 
them by a semicolon. In the following example, K is a local variable: 


F<[X Y¥;K]:deftinttton 


All functions defined as described above are used in prefix form--that is, 

the function name first, followed by the list of arguments. It is possible 

to cause the function name to appear anywhere among the arguments by placing 

a caret (A) at the point in the argument map where the name is to appear. 

For example, suppose that two numbers are to be combined in a predefined 

manner. The function that performs this combination could be defined so 

that its name appeared before, in between, or after its two arguments: 
COMBINE<+[X (WITH) Y]:deftnttton 


COMBINE 3 WITH 5 


or 
COMBINED+[X A (WITH) Y]:deftntttion 
3 COMBINED WITH 5 


or 
COMBINATION+[X Y A]:deftntttion 
3 5 COMBINATION 
No noise words may precede the caret. 
Function names may be picked up as arguments in character-string form by 
enclosing the bound variable in the argument map between double quote marks. 


For example: 


F<["V"] :definttton 
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This differs from picking up the argument in quoted form because the function 
is not structured with its arguments into a complete expression--only the name 
is passed. : 7 


It may be well to digress for a moment and explain that it is to character 
strings that assignment is made. The correct (and acceptable) form of the 
assignment expression is: 


Mates 


The double quotes may be omitted because the function + has an argument map 
that picks up its first argument in string form. 


["xX"' A Y]: asstgn Y to X 


If any other expression appears in the place where a string argument is to be 
picked up, it is evaluated normally. Consequently, indirect assignment is 
possible. For example: 
M< a ae 
assigns "N'" to M, and 
(M)<« 7 
assigns 7 to N 
Bound variables in a function have no connection or reference to variables 
with the same spelling that may be defined outside the function. For example: 
X<4 
F<«[X] 2X44 
The bound variable X in the function F is not the same X as the global or 
free X defined above and given a value of 4. Only the variables listed inside 
the argument map are bound. If X appeared in the definition of F but did 
not appear in F's argument map, then X would indeed refer to the free X defined 
outside. For example: | 
X<4 
F<[Y]:X+Y 


In this case, the X in the definition of F does refer to the X whose value 
is 4. | 


System Development Corporation 
28 June 1971 17 TM-4539/000/01 


Once a variable has been bound, it may be necessary to refer to the free 
variable of the same spelling. This is done by placing an exclamation point 
after the variable name. For example: 

X<4 

F<[X] :X+X! 

F 2 produces 6 
A third type of variable, in addition to the bound and free variables, is the 
globally bound variable. It is defined simply by placing an exclamation point 
after any bound or local variable in the argument map. A globally bound 
variable has the property that it will be bound not only in the scope of the 
defining function, but also in any function that is called in which it occurs 
free. For example: 

X<4 

F<[W X!]:X + GW 

G<«[Y] : Y+X 
In the above example, G is defined to be a function of one argument, which 
adds it to the value of the free variable X. A call to G, such as: 


10 + G 2 
would produce 16 as a result. However, F is defined with X as a globally 
bound variable in a definition that calls G. This effectively binds the 
X in G so that it is no longer referring to the free X. 

F 2 10 produces: 

10 + G2. which produces: 

22 
In all of the examples given above, the expression that was the function 
definition was specified explicitly as a quoted expression. The function 
definition must be quoted, but it need not be given explicitly. For example: 

F<[X Y]:SQRT Xt2+Y+2 


could be written as follows once EXPR is defined: 


EXPR«::SQRT Xt2+Y¥+2 
F<+[X Y] EXPR 
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The expression EXPR must be quoted twice when written so that it will return 
an expression when evaluated. In addition, the argument map itself may be 
saved by including a colon somewhere inside the brackets. 


ARGMAP<[: X Y] 
Now F may hecderiued: 
F < ARGMAP EXPR 
The variables in the argument map ARGMAP are bound in the expression EXPR. 


The argument map may be overridden at call time by explicitly specifying the 

number of arguments a variable is to possess. If the argument-forcing option 
is used, the function call must be in prefix form without any of the features 
normally available in the argument map. The number of arguments follows the 

variable name and is separated from it by a semi-colon. For example: 


G;3. argument argument argument 
causes the function G to pick up 3 arguments regardless of its current 


definition. 


Argument forcing is useful for functions that have not yet been defined, for 
functions that are intended to be redefined, or for forcing a function to 
pick up more arguments than its definition allows. In the latter case, the 
values of the extra arguments are assigned respectively to any local variables 
the function may possess. 


The function definition may be any expression at all, including other function 
definitions. For example: 


F<[X]: G<[Y]: YtxX 


In the above example, F is a function of one argument X, which, when called, 
defines another function G of one argument Y. The function G is not defined 
until F is called for the first time. Notice that the variable X is free 

in G but bound in F. The expression 


F 4 


would define G as Yt4. Every time F is called, G is redefined. 
A function could contain instructions to redefine itself: 


F<[N]:(1/N F<[X]:X/N) 
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The above function returns 1/N on the first call and X/N on every call after- 
ward. The following example shows a function F that redefines itself after 
every call: 


G«[Y]:F«[X]:G Y+X 


2.8 STATE CONDITIONS 


A state condition is a declaration of the environment in which further investi- 
gation is to take place. In order to specify a state condition, the user sim- 
ply encloses any UAL expression between vertical bars. The expression is 
evaluated at the time it is specified and returns a value of true or false 
according to the current state of affairs. From that time on, however, no 
actions will be allowed that would cause the state condition to become false. 
For example: 


|-1<FACTORS1 | 


If, after the above specification, an attempt were made to redefine FACTOR 
outside the given range: 


FACTOR<2.8 


the redefinition would not occur and FACTOR would retain its old value. 


The user may specify many state conditions that are active simultaneously 
either in a global context or local to a particular function. 


239 BUILT-IN FUNCTIONS AND LANGUAGE EXTENSIBILITY 


UAL has a vast number of helpful built-in functions. The functions fall 

into the following groups: arithmetic expressions, logical expressions, 
relational expressions, list manipulation, evaluation, iteration, conditional 
expressions, input/output, function editing, and function debugging. 


The iteration function is FORALL. This function evaluates an expression once 
for each member of a specified list and returns a list containing the result 
of each evaluation. For example: 


FORALL Xe{1l2... 50} 2+txX 


returns a list of powers of 2 from 1 to 50. The variable X in the above 
example is a control variable that assumes successive values from the specified 
list during iteration. The control variable is optional and has the status of 
a local variable throughout the scope of the FORALL function. 
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There are also options for skipping elements of the specified list or prematurely 
terminating the iteration. They are WHENEVER, UNLESS, WHILE, and UNTIL. Each 

of these functions must be followed by a logical expression and controls the 
iteration in a different manner. WHENEVER prohibits evaluation when its 

logical expression is false; UNLESS prohibits evaluation when its logical 
expression is true. WHILE and UNTIL terminate the iteration when their logical 
expressions are false and true, respectively. Any number of the qualification 
functions may be used in a FORALL and in any order. They must appear 
immediately after the specified list when used. For example: 


FORALL IeDATA WHENEVER I<O 8 I<<O 
places a lower limit of zero on the elements of the list DATA. 
Conditional expressions may be formed using the IF function of two arguments, 
which evaluates an expression only if the outcome of a given logical expression 
is true. The IFE function of three arguments evaluates one of two expressions, 
depending on whether the given logical expression is true or false. For 
example: 

IF FLAG="0N" & O<X<1 THEN (X*t2 FLAG<"OFF"') 

GRADE<IFE SCORE270 THEN ''PASS'" ELSE "FAIL" 


The noise words "THEN" and "ELSE" are optional. 


For the input/output group there are, among others, a PRINT function that 
causes values and lists to be printed and a READ function that requests an 
expression to be entered at the terminal. The expression is evaluated and 
the result returned as the value of READ. The function READQ treats the 
input as though it were a quoted expression. Through the use of these 
functions, new supervisors may be defined that handle input in nonstandard 
ways. For example: 


FORALL LOOP EVAL PRINT READQ 


echos back the input before evaluating it normally. 


PROGRAM+FORALL LOOP UNTIL (EXPR<READQ)="END~ EXPR 


EXPR stores a list of quoted expressions into PROGRAM for later evaluation. 


As shown above, the user may create an indefinite number of iterations with 
the predefined variable LOOP. 
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UAL has no special forms or special functions that are handled differently 
than user-defined functions. If the user is not satisfied with the operation 
of a particular function, he is free to redefine it to suit himself. For 
example: 


+ < [X A Y]:(X-Y)+2 


The above example redefines + to return (X-Y)+t2 rather than X+Y. 
7+3 produces 16 


or, + could be redefined as follows: 


+ < [X A Y]:(SUM X,Y INCREMENT C) 


where SUM is a built-in function that adds elements of a list and INCREMENT 
is a function that adds 1 to a variable. The redefined + still adds X and Y, 
but it also keeps track of the number of additions that have been made.* 


UAL, then, is extensible, which means that it is capable of redefining its 
own parts. (For other extensible languages, see Christensen and Christopher 
[1969], and Smith [1970].) 


2.10 THE CONTROL CHARACTER } 


The character # is a metacharacter used to control the input line that is 
being typed on a remote terminal keyboard. A carriage return is enough to 
enter a line for evaluation. The current input line may be deleted by typing 
# followed immediately by the letter D. 


* 
The function + could not be used in its own definition in this case, since 
that would have produced a recursive function. 
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14+24+3+#D4+5 


enters only 4+5. A specific number of immediately previous characters may be 
deleted by typing one or two digits after #: 


V+WHX+Y +3} 5+Z 


enters V+W+Z. Comments may be placed anywhere (even inside numbers and 
variable names) as follows: 


#[ comment | # 


The current input line may be edited character by character if a mistake is 
detected before the line is entered. The # is followed by two character 
strings separated by a comma and enclosed in parentheses. The current input 
line is scanned for the first occurrence of the first character string and, 
when a match is made, the duplicate is replaced by the second character string. 
For example: 


F<[X Y] >X+Y+Z}} cry eZ) 
would enter the line as if it had been written 


F<(X Z] :X+Y+2Z 
A second example: 


- QUES<"WHERE ARE Y#("ERE","'O")oU2" 
would enter as: 


QUES<"WHO ARE YOU?" 


Omitting the comma and second character strings deletes the match when found. 
A number may precede the first character string to indicate the occurrence. 


i} (4"E" : i a ; 


matches the fourth occurrence of E. 
The example above would enter as: 


QUES<"WHERE ARN'T YOU?" 
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The following list gives the possible characters that may appear after the 
control character and their meanings. 


#D Delete all of the current input line so far. 

#C Request for one continuation line. 

#[ Begin Comment. 

#] End Comment (also may be ]#). 

# ( Begin Edit Field. 

FW Wait - Request for an indefinite number of continuation lines. 

#E Evaluate - Process the input regardless of how many continuation 
lines have been requested. | 

#P Print out the current input so far and request one continuation line. 

# ! The # character itself. 

##hh Enter the character with hexadecimal representation hh. 

#dd Delete dd characters back. (One or two digits may be specified.) 


Deed PREDEFINED FUNCTIONS 


Many predefined UAL functions are available to the user. The argument map 
and a description of the definition is given with each function below. The 
type of argument required is indicated by its letter. 


- Number 

- Integer 

- List 

Character string 

- Variable name 

- Relational or logical expression 
- Any expression 


“Smo aI NCOrt Se 
i 


Any expression may serve as an argument for the above types as long as the 
value returned is of the correct type. 


Arithmetic Expressions: 


SQRT<[N]: square root 

SUM+[L]: adds elements in the list L 
SIN<[N]: sine 

COS<[N]: cosine 

ARCTAN<[N]: arctangent 

LOG<[N]: log to the base 10 

ELOG<[N] : log to the base e 

EXP<[N]: e" 


MAXIMUM<[L]: maximum element in L 
MINIMUM+[L]: minimum element in L 
INCREMENT<["V"]: adds 1 to V 


DECREMENT+["V"']:- subtracts 1 from V 
CONVNS<[N]: converts N to a character string 
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Character Strings: 
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CONCAT<[S1 (AND) $2]: string concatenation 
CHAR<[I (IN) S]: selects Ith character from S 


EXPLODE<[S]: 


COMPRESS<[L]: 


CONVSN<[S]: 
NAME<[S]: 


Logical Expressions: 


TRUE<1L 
FALSE<@ 
CONV@1<+[X]: 


Lists: 


COPY<[L]: 
ST<+[I A L]: 
ND<«ST 
RD<ST 
TH<ST 
ON<[I A L]: 
STN+ON 
NDN<ON 
RDN<+ON 
THN<ON 


returns list of single characters of S 


concatenates elements of L 
converts S to a number if possible 
converts S to a variable 


interprets an expression as true or false (0 or 1) 


copies list L 
selects Ith element of L 


returns remainder of list L from Ith element on 


APPEND<[L1 (AND) L2]: appends L2 onto the end of a copy of Ll 


LAST<[L]: 


last element of L 


LENGTH<+[ (OF) L]: number of elements of L 
JOIN<[L1 (AND) L2]: attaches L2 at node Ll. 


Evaluation: 


EVAL<[X]: 


VALUE<[!"'V"']: 
EVALST+<[S]: 
QUOTE<[X]: 


Operationals: 


RETURN<: 
RETURNR<[X]: 


SETOP<[X]: 
OPVAL<: 


evaluates X 

returns what V points to without evaluating V 

forms an expression out of the string S and evaluates it 
evaluates X and quotes the result. 


premature return from an operational (abbreviated RET) 

premature return from an operational with the result 
(abbreviated RETR) 

resets the value of an operational 

current value of the operational 
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Conditionals: 
IF<«[R (THEN) “X*]: evaluates X if R is true 
IFE<[R (THEN) “X1° (ELSE) ~X2°]: evaluates Xl if R is true and X2 if R 
is false 


Iteration: 


FORALL<[L (DO) “X“]: iterates X for each element of L 


WHENEVER+[R ~X7]: returns X if R is true, and "SKIP" if R is false 
UNLESS+[R “X7]: - returns "SKIP" if Ris true, and X if R is false 
WHILE<[R ~X7]: returns X if Ris true, and "STOP" if R is false 
UNTIL<[R ~X7*]: returns "STOP" if R is true, and X if R is false 
IN<["V" A L]: returns {"IN" V L} 

LOOP<: list of indefinite number of elements 


State Conditions: 


STATES<: prints out a list of state conditions with reference numbers 
DELSTATE<[I]: deletes state condition number I 


Input/Output: 
READ<: returns an evaluated expression from the terminal 
READQ<: returns a quoted expression from the terminal 
READST<: returns terminal input as a character string 
SPECIFY<['"'V"]: asks for an input from the terminal and assigns it to V 
PRINT<[X]: formatted print 
OUTPUT<[X]: unformatted print 
STASH<[X]: holds X until the next PRINT or OUTPUT is called, then 
outputs X 
PRINTOFF<: deactivates automatic printing of value of every expression 
that is entered 
PRINTON<: activates automatic print 
Debugging: 


LINEPROMPT<+[S]:changes line prompt to string S 
STACKSTATUS<: prints out current status of waiting argument stack 


FREESPACE+<: calls garbage collector and prints out number of words of 
freespace left 
FREE<["V"']: returns variable V to free storage 
MORENAMESPACE<: gets more space for variable names 
TYPE<[X]: gives type number of X 
Protection: 


UNPROTECT<["'V"]: unprotects variable V for redefinition 
PROTECT<["'V"']: protects V : 
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3. USE OF UAL: AN EXAMPLE 
3.1 PO&M SYSTEM (PLANNING ORGANIZATION AND MANAGEMENT SYSTEM) 


The following example is taken from "An On-Line Interactive Hierarchical 
Organization and Management System for Planning," [Kleine and Citrenbaun, 


The problem is that of convention planning. Let us suppose that a chairman 
has already been selected for setting up a large convention or conference. 

The chairman, possibly with other co-chairmen and assistants, now proceeds 

to define a number of areas of responsibility or activities that can be 
delegated to other individuals. He might define the areas such as "publicity" 
and "accommodations" and assign individuals to head the areas and their 
assistants. These heads, who have been appointed by the chairman, may 
themselves delegate portions of their tasks to their subordinates. Thus a 
hierarchical structure results, with "nodes" representing subdivided areas 

of activities. 


A representative hierarchical organization created by a planning group to 

meet the needs of convention planning is shown schematically in Figure 2. 

Here the CHAIRMAN has set up a CHAIRMEN's COMMITTEE and TREASURER, PUBLICATION, 
MEETING ROOM, PUBLICITY, and LUNCHEON ACTIVITIES. He will define the duties 
and responsibilities of each Activity, name a head and staff members as 
appropriate, and communicate with and request reports or information from them 
as the planning proceeds. He will also create additional Activities as the 
need arises and delete those whose work is completed. The TREASURER establishes 
formal communications and reporting relationships with the major Activities, 
and PUBLICATIONS sets up a subactivity, PRINTING, which PUBLICITY also uses 
for its printing needs. 


Formalizing the Concept of Activity. Let us consider the elements needed 

in the PO&M system in order to assist the planners in setting up their 
organization and communicate within it. First, all of the information which 
might be associated with an activity is listed (Figure 3). This includes 
the name or title of the Activity; a description of the job to be done by 
that Activity; a status indicator to tell others whether the activity is 
unstarted, finished, working, or waiting. It also includes a set of links 
connecting the Activity with superiors, subordinates, and associates on the 
same level. These links are used for normal instructions, reports, and 
communications. Communication can take place outside of these channels, but 
automatic distribution of information down through the organization and the 
forwarding of reports upward takes place along these lines. 


PUBLICATIONS 


PRINT 


iG 


TREASURER ée 


<x | 


MEETING ROOM 


PUBLICITY LUNCHEON 


Figure 2 
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ACTIVITY © 


NAME 
DESCRIPTION 
STATUS 
LINKS: 
SUPERIOR: 
PARENT: LINK, NAME, FORWARD, DATA 
OTHERS 
SUBORDINATE 
LATERAL 
MEMBERS: HEAD, OTHER MEMBERS 
DURATION 
RESPONSE: REQUESTED, EXPECTED 
TASK INPUT 
TASK OUTPUT 
DATA 


GROUP 


NAME 


LINKS: SUPERIOR, SUBORDINATES, LATERAL 
MEMBERS: | 


e 


Figure 3 
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Each of the three communication-link types consists of groups of links. The 
first of the superior links is the parent or direct superior link. Each link 
is itself made up of a link-pointer, which points to the associated activity; 
the name of the linkage; an indicator whether information is to be auto- 
matically forwarded along this path; and any data and/or textual information 
used with this communication link. MEMBERS is also a group in which each 
element is an individual member of the group associated with the Activity. 
The head of the group is listed as the first member and, if there is no head, 
that position is left empty. 


DURATION is the best estimate of the total duration of this Activity. RESPONSE 
is composed of two parts: (1) REQUESTED, the response interval requested 

by the inquiring party, and (2) EXPECTED, the anticipated interval before this 
Activity responds to the inquiry. The TASK INPUT is a combination of data 
and/or text information specifying the task requirements of this activity. 
Similarly, TASK OUTPUT contains the results of the Activity's work, and DATA 
contains information accumulated for use in accomplishing the Activity's 

tasks. (For the sake of readability, the underline character will be used 

in the formation of variables and should be considered a letter.) 


Organizational Elements. A given activity may not need or make use of all 
of the elements described above, but all categories remain available for use 
as required. Organizational types other than activities--such as groups-- 
can be accommodated using some sublist of the elements in an Activity: 


Designer/User Notation. A system can be built in UAL from the above general 
PO&M system requirements. Two types of instructions will be given in the 
language: the "system designer" will write instructions to build up the 
elements of the system, and the "project organizer" (the user) will write 
instructions in the new language of the augmented UAL system--that is, in 
the language of the UAL that has been augmented with PO&M system—building 
functions. 


3.2 PRIMITIVE FUNCTIONS AND BUILDING BLOCKS FOR PO&M SYSTEM 


In the following figures, the system designer's instructions will be in 
capital letters and those of the organizer-user will be in capitals with 

each instruction line set off with an asterisk. The designer will initially 
need to formalize the concept of an Activity and the elements of which it is 
composed. This can be done by treating an Activity as a list of data elements, 
some of which are lists themselves. 


Figure 4 shows an example of the CHAIRMAN organized as an Activity. The 

lines represent the links of the Activity with other Activities and with 
individuals and their records. The entire Activity list is a rigidly formatted, 
non-user-oriented structure. It is necessary, for example, to ask for the 
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value of the third part of an Activity in order to determine its status. 

The first step, then, in system design is to enable names to be used to access 
each part of an Activity while leaving the structural integrity of the Activity 
as a whole undisturbed. 


Use of Names for Structure Parts. In Figure 5, NAME is defined as an expression 
that, when applied to an Activity ACT, will yield as its value the first or 

name part of that Activity. If NAME were applied to the chairman's Activity, 

it would yield "CHAIRMAN" as the value for the expression. Similarly, DESC 

and STATUS yield the description and status parts of an Activity. The list 

of superiors is the first item of a three-part list, which, in turn, is the 
fourth part of the Activity. The "parent" is the first item of the list of 
superiors, and so forth. 


In a similar fashion, each of the elements or collections that make up an 
Activity is defined in a way that permits those elements to be referenced by 
name rather than by location within the structure. 


Note that the definition of SUPERIOR has a "TO" inside the argument map. 
This permits the word to appear optionally in each use of the functional 
operator "SUPERIOR." For example, one could write SUPERIOR PUBLICATIONS or 
SUPERIOR TO PUBLICATIONS. Making use of these basic expression definitions, 
the designer can now build higher-level expressions. : 


- Defining Activity-Creating Functions. One of the first things a user will 


want to do is to create one or more Activities. The first definition in 
Figure 6 permits this. The expression CREATE A CHAIRMAN creates the Activity 
CHAIRMAN, sets the name to be the word "CHAIRMAN", sets the status to "NOT 
STARTED", and leaves the remainder of the Activity's structure temporarily 
undefined. It also makes the Activity just created the value of CUR TITLE 
(current title). The instruction WITH modifies the Activity that is the 

CUR TITLE by inserting a name at the beginning of the MEMBERS list so that the 
name will be treated as the Activity head. | 


The function MEMBERS allows specification of the members other than the head. 
The function MAKE operates on two arguments and can insert a given name or 
value into any given position of an Activity. The last function, REORGANIZE, 
changes the Activity that is the CUR TITLE and, therefore, the Activity that 
is changed by the WITH and MEMBERS instructions. With this handful of 
definitions, the user can write any of the instructions shown at the bottom 
of Figure 6, as well as an extensive number of others made up of various 
combinations of the newly created instructions. 


"Top-Down" vs. ''Bottom-Up'"' Approaches. The above is an example of "bottom-up" 


system design. Basic expressions were defined, and, out of these expressions, 
successively higher-level, user-oriented functions were defined. We will 
turn now to the capability of reversing this procedure in UAL. 
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ACTIVITY 


{NAME DESC STAT {SUP SUB LAT} MBRS DUAR RESP INPT OUTPT DATA} 
NAME<[(OF)ACT]: 1 ST ACT 
DESC<+[(OF)ACT]: 2 ND ACT 
STATUS<[ (OF) ACT]:3 RD ACT 
SUPERIOR<[(TO) ACT]: 1 ST 4 TH ACT 


PARENT<[ (OF) ACT]: 1 ST 1 ST 4 TH ACT 
SUBORDINATE<[ (OF) ACT]: 2 ND 4 TH ACT 
ASSOCIATE<[ (OF) ACT]: 3 RD 4 TH ACT 


HEAD<[(OF) ACT]: 1 ST 5 TH ACT 
MBRS+[(OF) ACT]: 2 ON 5 TH ACT 
CMTT+[(OF) ACT]: 5 TH ACT 
DUAR * °° 

RESPR 

RESPE 

TASK INPUT 

TASK_OUTPUT 

DATA 


Figure 5 
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CREATE « [(A) "TITLE']: CUR-TITLE <« TITLE, 0, "NOT STARTED" 
WITH « ["NAME" (AS HEAD)]: (HEAD OF CUR TITLE) + NAME 
MEMBERS < ["MEMB"]: (MBRS OF CUR TITLE) << MEMB 
MAKE < ["NAME'" (A) POSITION]: (POSITION) << NAME 
REORGANIZE « [(THE) "ACT"]: CUR_TITLE <« ACT 
* CREATE A CHAIRMAN 
* MAKE MR_ K HEAD CHAIRMAN 
* CREATE A CHAIR COMMITTEE WITH MR_ A AS HEAD MEMBERS MR_ B, MR_ C 
* MAKE CONTROLLER SUPERIOR TO PARKING 


* REORGANIZE THE PUBLICITY COMMITTEE WITH MR D AS HEAD 


Figure 6 
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"Top-down" design begins with the final desired expression form and then breaks 
that down into its constituent parts until there are no undefined parts. 

The user can indicate, for example, that he would like to be able to say "WHAT 
IS THE VALUE OF THE PUBLICATION '"TOTAL-EXPENSES", and get an automatic 
response from the system, if the PUBLICATION group has defined its total 
expense in some form (see figure 7). The designer can start out by defining 
WHAT, a function that will be expected to find the definition that PUBLICATION 
has created for its total expenses. After writing the definition for WHAT, 
the designer can later complete the definition of any of the undefined parts 
of the expression. In this case, since EXPRESSION is undefined, a definition 
for it is provided next. Finally, the function DEFINE is defined. This last 
function can be used to add values or value-expressions to the TASK OUTPUT 

of an Activity where they can be automatically interrogated by a superior 
Activity. An example of this is shown at the bottom of Figure 7. 


Use of Expressions Defined by Other Activities. The chairman requests 
PUBLICATION to set up and keep current a best estimate of total costs. 


PUBLICATION does this and defines it based on its costs and the best cost 
estimate of the PRINTING subactivity. Now, when the Chairman interrogates 
PUBLICATION for total costs, not only will PUBLICATION calculate its costs and 
automatically respond, but PUBLICATION will automatically ask PRINTING for 

its current best estimate of costs. 


MEMO Communications. The last area the system designer will deal with is 
communication. There are three types of communications or MEMO's: instructions, 
notes, and reports. Instructions are MEMO's from a superior to a subordinate; 
reports are MEMO's from subordinate to superior; notes are lateral flows of 
information. If not otherwise specified, MEMO& are of the same type as the 
relationship. For example, if an Activity sends a MEMO to a subordinate, it 
is an instruction unless otherwise indicated. Reports are automatically 
forwarded upward through those Activities designated by the user. Similarly, 
instructions are distributed downward automatically under the control of 
forwarding instructions. Although the report is the default MEMO from a 
subordinate, the subordinate may, if he wishes, specifically send a note to 
his superior in order to directly communicate information that he did not 
wish to be forwarded. In a similar fashion, notes or even reports can be 
sent. 


Setting Up Basic Communication Functions. An example of the type of definitions 


needed for communication is shown at the top if Figure 8. The head of an 
Activity may wish to have an instruction that will give him all his messages 
when he checks with the system. Such a function is CHECK IN. The second 
definition for CHECK IN (shown after "of:"'), instead of printing all MEMO's 
received to date, prints those now in the TASK INPUT, and then transfers 
these to a MEMO-list for a record of past MEMO's. He could even use a MEMO- 
checking function, which automatically checks for MEMO's at regular hours of 
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TOP DOWN 
* WHAT IS THE VALUE OF THE PUBLICATION "TOTAL EXPENSES" 
WHAT «+ [(IS THE VALUE OF THE) ACTIVITY LABEL]: 


EXPRESSION FOR LABEL OF THE TASK OUTPUT OF ACTIVITY 


EXPRESSION <« [(FOR) LABEL (OF THE) LIST]: 
FORALL ITEMS IN LIST IF (NAME OF ITEMS)=LABEL THEN RETURNR 2 ND ITEMS 
DEFINE + ["LABEL" (TO BE THE) VALUE]: 


(DATA OF MY ACTIVITY)<« LABEL, VALUE 
CHAIRMAN 
* MEMO FOR PUBLICATION COMMITTEE : "SET UP TOTAL COSTS COMPUTATION" 


PUBLICATION 


% DEFINE TOTAL COSTS TO BE THE SUM OF COST OF MATERIALS, COST OF PREPARATION, 
COST OF DISTRIBUTION + WHAT PRINTING TOTAL COSTS 


CHAIRMAN 


* WHAT IS THE VALUE OF THE PUBLICATION "TOTAL EXPENSES" 


AUTOMATIC SYSTEM RESPONSE 


2137 


Figure / 


MEMO < [(FOR) ACT (:) TEXT]: (TASK INPUT OF ACT) + APPEND TEXT AND TASK INPUT OF ACT 


CHECK IN + : FORALL MEMOS IN TASK INPUT OF MY ACTIVITY PRINT MEMOS 


or : IF (TASK _INPUT OF MY ACTIVITY) # @ 


THEN FORALL MEMOS IN TASK INPUT OF MY ACTIVITY 


(PRINT MEMOS APPEND MEMO AND MEMOS LIST) 
REPORT <« [(TO) ACTIVITY (:) TEXT]: 
INSTRUCT < [(TO) ACTIVITY (:) TEXT]; 


NOTE « [(TO) ACTIVITY (:) TEXT]: 


Figure 8 
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the day and, based on the anticipated contents, takes appropriate action--all 
without direct intervention. 


The foregoing is intended to be not an exhaustive development of the PO&M 
system but an indication of (1) the type of system that could be developed, 
(2) the instructions needed to establish such a system, and (3) the power 
and flexibility of UAL in building other, quite different systems on top of 


itself, complete with a modified supervisor, new vocabulary, and altered 
language syntax. 
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APPENDIX A 


A UAL TERMINAL SESSION 


The following is taken from a demonstration of UAL on the IBM 360/67 ADEPT 
Time Sharing System using an Execuport 300 terminal. (See Appendix B for 
minor character conversions.) The session covers expression formation, 
character string manipulation, assignment, list manipulation, operationals, 
evaluation and inhibiting, extensibility and protection, function definition 
and argument maps, conditionals, iteration, argument forcing, input/output, 
state conditions, the control character #, and function defining functions. 
User inputs occur after the preset lineprompt of #. Computer replys are 
indented except in the case of a non-formatted print. 


# 21+45 expresston formatton 
66 


fe $+2 ¢ contains value of last expresston 
68 | 

# 543 

# 5.8-3.74 

## 50/2%5 

## 4<7 true=1 false=0 

# 5>5 

# 5>=5 


# "HELLO" character strings 
HELLO 


# CONCAT "HELLO" " THERE." 
HELLO THERE. 


28 June 1971 


if ter 
EMPTY STRING 


if TY AeA 
A'A. 


if Nota 
6 


# "5 FEET"+1 


# A 


## B<7 


# A=B 
+ A== 
# B<A 


# A==B 
1 
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getting " character tnto a string 


automatte converston 


assignment 
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# {1 2 3} 
' LIST 


itsts 


END 


# 2 ND {2 4 6} 
h 


# {1 2 14 
LIST 


END 


# 2 ND 3 RD $ 
5 


4 TH {7 8} 
NO VALUE © 


# 13 
EMPTY LIST 


# 3 ON {1 2 3 4} 
LIST 
3 
4 
END 


# APPEND {1} {5 6} 
LIST 


1 
5 
6 


END 
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END 


# L<«{1 35 7} 
LIST 


“SUT WD 


END 


# E<3 RD L 
5 


#} E<<6 
6 


# lL 
LIST 


SO WE 


END 


# (3 RDN L)<<10 
10 


# L 


# E 


28 


# 


# 


# 


# 


# 


# 


# 


# 


System Development Corporation 
June 1971 45 TM-4539/000/01 


K<«(PRINT "A" PRINT "B" PRINT "C") operattonals 


A 

B 

C 

A last A ts value of enttre expression 
K 

A 
K+(PRINT "A" PRINT "B' SETOP "C'" PRINT "D" RET PRINT "E") 

A 

B 

D 

C 
K 

C 
D1<5 evaluation and tnhtbiting 

bs) 
D2<'D1! The word EXPRESSION ts substttuted for 

EXPRESSION the printout of the .value when tt would 

be a stmple repeat of the input. 

D2 

5 
D3<:D2 

EXPRESSION 
D3 

5 
D4<: :D3 

EXPRESSION 
D4 

D3 

EVAL D4 


5 
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i## P<VALUE +  extenstbiltty and protection 
UAL PRIMITIVE 3 


#3P4 

i} +<17 
«+ ASSIGNMENT ATTEMPTED ON A PROTECTED VARIABLE. 
17 


## UNPROTECT + 
NO VALUE 


# 4<17 
17 


#t + | 
17 
# + P 2 

19 


## +<VALUE P 
UAL PRIMITIVE 


# 1+1 
2 


{# PROTECT + 
NO VALUE 


## COMBINE+[X (AND) Y]:Xt+2+Y+2 funettons 
EXPRESSION 


## COMBINE 3 4 
25 


## COMBINE 3 AND 5 
34 


= 


COMBINED<[X @ (WITH) Y]:X+Y+10 
EXPRESSION 
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# 2 COMBINED WITH 3 
15 


## COMBINATION<[X Y-@] :X*Y*2 
EXPRESSION 


# 4 5 COMBINATION 
40 


# N<4 tndtrect assignment 
4 


# M<"N" 
N 


# (M)+44 
44 


# M 


# N 
44 


## EXPR«<: :X*Y*Z argument map saving 
EXPRESSION 


i 


“hy 


ARGM<«[: X Y Z] 
ARGUMENT MAP 


i## MULT3<«ARGM EXPR 
[X Y Z]:X*Y*Z 


# MULT3 2 3 4 
24 

# IF 2<4 THEN "OK" condtttonals 
OK 


# LF 4<2 THEN "OK" 
NO VALUE 
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i} 


# 
# 


# 


if 


iF 


# 


# 


i 


iF 


IF 2<4 THEN (N<45 PRINT "DONE") 
DONE | 
45 


45 


IFE 2<4 THEN "OK" ELSE "NO GOOD" 
OK 


IFE 4<2 "OK" "NO GOOD" 
NO GOOD 


FORALL X IN {2 4 6 8} Xt2 forall 
LIST 


END 


FORALL X IN {5 12 7 20} WHENEVER X>10 2+X 
LIST 
4096 
1048576 
END 


G«[X Y;Z] :X*Y+Z argument forcing 
EXPRESSION 


PRINTOFF | tnput/output 


2+2 
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## PRINT $ 
4 


# SPECIFY S 
PLEASE SPECIFY S. 


# 145 


# PRINT S 
145 


# OUTPUT S 
145 


# STASH " S=" 
## STASH S 


# OUTPUT "'."' 
S=145. 


# OUTPUT {1 2 3 7} 
1237 


## PRINTON 
NO VALUE 


i## DREAD 


# 4 This tnput ts under the control of READ 


# D 


# READ 


# 2+2 This tnput ts under the control of READ 


## READQ 


# 2+2 


# EVAL $ 
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it M<10 state condtttons 
10 


# |M<12| 
1 


# M<5 
be) 


# M<15 
ATTEMPTED VIOLATION OF STATE CONDITION 1. 
15 | 


# M 
5 


# STATES 
CURRENT STATE CONDITIONS: 
(1) M«12 
DONE 
NO VALUE 


# N<13 
13 


# |N>m| 
iL 


# N<7 
7 


# N+L 
ATTEMPTED VIOLATION OF STATE CONDITION 2. 
1 


# N 
7 


# STATES 
CURRENT STATE CONDITIONS: 
(1) M<12 
(2) NM 
DONE 
NO VALUE 


## DELSTATE 1 
NO VALUE 
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i 


# 


= 


# 


i 
# 
i 
i 


# 


iF 


STATES 
CURRENT STATE CONDITIONS: 
(1) CANCELLED 
(2) N>M 
DONE 
NO VALUE 


N<24 
24 


M<15 
15 


1+2+3+4#D5+6 
11 


14+24+3+4#C 


+5 
15 


#C'ABCDE 


FGH" 
ABCDEFGH 


"ABCDE#3FGH" 
ABFGH 


#W" ABCDE 
FGH 
IJK 


LMN"#E 
ABCDEFGHIJKLMN 


"AAHIAA" 
AA#AA 


"AA#[YES THIS IS A COMMENT]#AA" 
AAAA 
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# N#[IN A NAME]J#N<5#[IN A NUMBER]#5 
55 | 


# NN 
55 


# MN<15 #("'N",'"M") 
15 


i## MN 
NO VALUE 


# MM 
15 


= 


M<+15*(12+8) #P 
M<+15*(12+8) 


df i cy" : mo) 


ATTEMPTED VIOLATION OF STATE CONDITION 2. 
500 


# "ABCD#H24EFG" "24" ts the hexadectmal code for 
ABCD line feed. 
EFG 


# "1234##OF567" 'Or" ts the code for carrtage return. 
1234 © 
567 


## LINEPROMPT "##OF> " miscellaneous functtons 
NO VALUE 


> J+1 
2 


> LINEPROMPT "###24#! "' 
NO VALUE 


## SQRT 2 
1.414213562373094 
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# EVALST "2+2" 


4 
## FREESPACE 
35201 
# (2%5 8<4 D<«{1} 2000 STACKSTATUS RETR 0) 
LIST 
2000 
LIST 
1 
END 
@) 
10 
END 
) 
# R1<[X]: R2<+[Y]: Ytx funetton defintng funettons 
EXPRESSION 
# R25 
NO VALUE 
# R1 3 
[y]:¥t3 
# R25 
125 
# RL 4 
[y]:yt4 
# R25 


625 
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APPENDIX B 


PRECEDENCE 


The before-and-after precedence for predefined functions is as follows: 


BEFORE AFTER 
0 + 14 
0) amie x 14 
1 ST 2 
3 d _ 
3 + 4 
5 x 5 
6 / 6 
7 + 7 
7 - 7 
8 < 8 
8 < 8 
8 = 8 
8 # 8 
8 == 8 
8 > 8 
8 > 8 

-- : 9 
10 6 10 
11 v 11 
12 > 12 
13 z 13 
13 Z 13 
14 14 


15 functions 16 
_— : 16 


The lower-numbered functions are combined first, that is, have the highest 
precedence. In cases of equal precedence, combination done from left to right. 
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APPENDIX C 


CHARACTER CONVERSIONS 


UAL TELETYPE EXECUPORT 300 
Opening Grouping Parenthesis ( ( ( 
Close Grouping Parenthesis ) ) ) 
Open Operational ( ( ( 
Close Operational > ) ) 
Open List if << { 
Close List } >> } 
Open Character String . . . 
Close Character String . ' ” 
Open Argument Map [ [ [ 
Close Argument Map ] ] ] 
Open Quoted Expression ~ ' : 
Close Quoted "xpression . ; 
Open State Condition | ‘ | 
Close State Condition | x | 
Open Quoted Argument* . : : 
Close Quoted Argument* a ' ' 
Open String Argument* " m i 
Close String Argument* ” . . 
Blank Space b Bb b 
Line Prompt ff if # 
Logical Implication a none none 
Logical And & & & 
Logical Or V V V 
Logical Negation 7 none “ 
Assignment (Definition) < os < 
Assignment (Change) ete ag pipe 
Exponentiation t + t 
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APPENDIX C (Cont'd) 


UAL TELETYPE EXECUPORT 300 
Integer Division - // // 
Division / / / 
Multiplication | * * ms 
Subtraction - = = 
Addition + + ~ 
Function Name Positioner* us @ @ 
Less Than < S : 
Less Than or Equal to ae <= as 
Equal to = = | s 
Not Equal to # /= ‘ss 
Greater Than or Equal to 2 >= as 
Greater Than > 6 @ 
A Member of € IN IN 
List Formation ‘ ’ ’ 
Argument Foréing : 5 3 
Open Local Variable List* : ; 5 
Decimal Point 
Expression Quote 
Argument Map Quote* 
Identically Equal to == == == 
List Continuation ae ate 
Line Entry cr er er 
Character Delete #tdd #dd or rubout #dd or bs 
Line Delete #D #D or break #D or break 
Global Variable ! ! ! 
Percent | vA hs ho 
Value of Previous Expression ) =) S 
Unused 4 ? 2 


*Found only in the argument map 
er = carriage return 
bs = back space 


pb 


I 


blank space 
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APPENDIX D 


UAL SYNTAX 


<digit>::=@/1/2|3|/4/5|6|7/8|9 

<letter>::=A|B|C|D|E|F|G|H|1I|J|K|L|M|Nio|Plq|R|s|Tlu|viwixl|y|z 

<integer>::=<digit> |<digit><integer> 

<real>::=<integer>. .<integer>|<integer>.<integer> 

<number>: :=<integer> | <real> 

<variable>::=<name>|<symbolic name> 

<symbolic name>::=+|-|*|/ eA <|<|= # 
& |= | FH e] so (@ [ees 

<name>::=<letter><alpha-num sequence> 

<al pha-num sequence>::=<alpha-num> | <alpha-num><alpha-num sequence>|<empty> 

<alpha-num>: :=<letter>!<digit> 

<character string>::="<string>" 

<string>: :=<character> <character><string> | <empty> | 

<character>::=<letter> <digit>|<symbolic name>|(|)|[]]|""] {|} 


ze haat b aly 


< 


<empty>::= 


<expression>: :=<function name><argument list >|<list>|<operational>| 
<character Bde pai ae 
<function definition>|<state condition> | <empty> 
<state condition>: :=}<expression> 
<list>::={<expression sequence> } 
<expression sequence>: :=<expression> | <expression><expression sequence> 
<operational>::=(<expression sequence>) 
<function name>: :=<variable>|<qualified variable> 
<qualified variable>: :=<variable>;<integer> 
<argument list>::=<expression sequence> 
<function definition>: :=<argument map><quoted expression> 
<quoted sare NE Sete nie Ce Fhe ae a 
<argument map>::=[<bound variable list><local variable specification>] |<empty> 
<bound variable list>::=<bound variable>|<bound variable><bound variable 
list>|<empty> 
<bound variable>::=<variable>|(<variable>) |~<variable>~|'<variable>"| 
<variable>-:|:|A|<integer> | 
<local variable specification>::=;<local variable list>|<empty> 
<local variable list>::=<local variable>|<local variable><local variable list> 
<local variable>::=<variable> |<variable> 
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